The traditional approach to the design of information management systems using relational databases typically progresses through five mutually exclusive stages:                define business requirements;        design table structure (data schema);        program tables and store procedures;        program application and interface;        test and deploy system.        
The overall timeframe for application development is dependent on sequentially completing each stage and then moving on to the next. For example, all of the business requirements must be completely defined before the structure of the database tables and fields, as well as their relationships, can be designed. Similarly, the table structure must be completed before the access routines can be written. Based on the completed data schema and procedures, the software programmers then start to develop the business modules and corresponding user interfaces.
The traditional approach can take considerable time. Making changes to a previously completed stage turns into a time consuming process requiring the developers to go “back to the drawing board” and re-work what was already completed. The design phase is most critical because fundamental decisions are made about the general use, purpose and shape of the application. If this foundation work is flawed, it is extremely difficult and expensive to correct later. If there are design weaknesses, the entire process has to be backed up and repeated.
Conventional relational database management systems (RDBMS) are typically built using a fixed data architecture, where this fixed data architecture consists in fixed data structures such as data fields, memo fields, records, spreadsheets, data files, indexes and relationships. Specifically, a data model, including a fixed physical data structure and data access routines, is designed and implemented based on predetermined business rules and requirements known at the time of design. This data model often determines the success or failure of the resulting application. Unfortunately, once completed, changes to this data model in order to implement new requirements are very difficult, due to limitations imposed by the fixed data structure and the dependence of the data model thereon, such that both the data structures and the business rules become locked in to each other.
Consequently, the life span of the traditional information management system is relatively short, as the completed data model rapidly becomes obsolete in the face of new and evolving business requirements. The fixed data architecture limits the growth of the system, as the overall system is unable to evolve to address future business needs and requirements.
Furthermore, relational database management systems often have difficulty integrating with modern object-oriented application development, which introduces objects defined by dynamic templates that are able to adapt and change according to the needs of the application. This is due to the fact that the fixed data structure of the conventional relational database management system originated at a time when business requirements were known well in advance of the system design and were not expected to change once systems were designed and deployed. Thus, the fixed data structure used by relational database management systems is a severe bottleneck in the development, life cycle and flexibility of any data-centric software solution.
A common solution to the limitations of the existing RDBMS engines is the regular re-working of the fixed data architecture, time and time again, in order to implement new business processes. When unforeseen applications require access to the data schema previously developed for an existing RDBMS, another possible solution is the development of separate databases that run independently from the original database, even though some data may be duplicated in both the original and new databases. Such solutions are expensive, time consuming and extremely inefficient.
Against this background, a need exists in the industry for an improved data architecture for information management systems using conventional DBMS engines.